Today, practically all web servers, clients and related web applications talk to each other through HTTP. The communication is based on HTTP requests and responses between clients and servers, for which HTTP defines a request response protocol. Every time a client sends an HTTP request, the web server returns a MIME (Multipurpose Internet Mail Extensions) header. The start line of the response reads:<version> <status code> <reason phrase>
The version part refers to the version of HTTP used for the message. The status code is a three-digit code number roughly indicating what happened during the request. Status codes are grouped into general classes, which are described by the first digit. For example, codes on the format 2XX means “success”, whereas 4XX and 5XX codes indicate “client error” and “server error”, respectively. The reason phrase, finally, is a human readable version of the code number, the features of which will be described below. The standard HTTP response to a successful GET request is:HTTP/1.0 200 OK
The above line is typically followed by further header information, such as content type and length, and then the requested document.
A commonly used prior-art communication network comprises a web server communicating with a client terminal via a proxy server (generally referred to as “proxy”). The proxy shuffles HTTP messages back and forth between the server and client. More specifically, the proxy conveys each request, which is based on HTTP or on the Wireless Session Protocol (WSP), from the wireless client to the web server and each subsequent HTTP response from the web server to the client. The start line of the response passes the proxy unchanged and the end-user receives a response message directly corresponding to the response sent from the web server.
Now assume that the server encounters an error and reports that in the HTTP response. For such a case (HEAD requests excepted) the HTTP protocol states that the server “should include an entity containing an explanation of the error situation” in the response (“Hypertext Transfer Protocol—HTTP/1.1”, RFC 2616, R. Fielding et. al., June 1999). Furthermore, user agents “should display any included entity to the user”. This means that there may—or may not—be an explanation entity, i.e. a reason phrase, incorporated in the response message. Furthermore, even when there is a reason phrase it is not certain that it will be presented to the end-user. Sometimes only the error code is displayed. The provider of the requested service, e.g. a mobile operator, cannot possibly know what will happen in a particular error situation.
Moreover, even if a reason phrase is shown, it may reflect the actual error situation very badly or even erroneous. The HTTP specification does not provide any guidance on the exact text for reason phrases, which are therefore rather arbitrary. Consequently, the end-user might get the wrong impression of the service provider, which is a very serious problem since it reduces the value of the service in the eyes of the user.
Accordingly, conventional handling of HTTP error messages is far from satisfactory and there is a considerable need for an improved error messaging method.